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Sir: 

This Reply Brief is submitted under 37 C.F.R. § 41.41 in response to the 
Examiner's Answer dated August 30, 2011. The Examiner's response to 
Appellants' arguments submitted in the Appeal Brief of July 5, 2011 raises 
additional issues and underscores the factual and legal shortcomings in the 



Examiner's rejection. In response, Appellants rely upon the arguments presented in 
the Appeal Brief of July 5, 2011, and the arguments set forth below. 



Appellants' exemplary claim 14 recites: 

14. A computer-implemented method for processing contract data associated 

with services to be provided via a network in an infrastructure, in which a 
plurality of binding contracts exists between a service provider and a service 
requestor for services having a respective number of service specifications, the 
method comprising: 

creating said contract data comprising contract selection parameters for 
subsequently selecting at least one service contract out of said plurality of 
contracts; 

including said contract data into a request for said service; 

issuing, via the network, said request for said service; and 
receiving, via the network, the service according to a selection of the at 
least one service contract based upon the contract selection parameters. 



In the Appeal Brief, Appellants argued the following: 

An important aspect of the Appellants' claimed invention is to include contract 
selection parameters into the service request (particularly into the query string of 
the endpoint address of the request) so that the requestor can have influence on 
the contract selection. Dan discloses the development of the contract enforcement 
code and its integration with a service application. However, Dan does not 
disclose using the contract selection parameters to select at least one service 
contract out of a plurality of contracts (Dan concerns the enforcement of one 
contract, not the selection among multiple contracts). Dan further does not 
disclose the inclusion of the contract selection parameters into a request. 

Reid does not cure the deficiency of Dan. Reid discloses a database that 
may be searched for particular agreements based on several parameters. 
However, Reid does not disclose that the parameters are included in the service 
request. 



In response. Examiner stated on pages 19-20 of the Examiner's Answer the 
following: 
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Applicant argues that Dan does not disclose "including said contract data 
into a request for said service." Examiner respectfully disagrees. As Dan explains 
in the quoted passage from col. 7, line 24 thru col. 8, line 20, a contract 
enforcement code is generated and used by the requester. The code determines 
whether the request is allowed. If the requester has a valid code, the contract 
enforcement code then invokes the appropriate action. 

Applicant further argues that Dan is concerned with the enforcement of 
one service contract, not the selection of one service contract from among a 
plurality of contracts. While Dan does not teach this on its face, Examiner has 
provided applicant with Reid, which specifically teaches this aspect of the 
invention. Reid allows a user (which may be a person or a computer) to search for 
a contract based on several different fields (paragraph 35). 

Examiner anticipates the possible argument that Reid should not be 
combined with Dan. Dan, however, is enhanced by Reid. Dan discloses providing 
services according to a contract between the customer and the service provider. 
Reid teaches selecting a particular contract from a database. When combined, 
Reid gives Dan more flexibility since Dan ostensibly provides for only one 
service contract for all customers, but when combined with Reid, Dan has the 
ability to provide multiple service contracts for different customers, or even the 
same customer. This allows Dan to provide different levels of service for different 
types of service or customers. Most providers have more than one customer, so 
this increases Dan's ability to meet customer needs. 



For the convenience of the Honorable Board, col. 7, line 24 to col. 8, line 20 
of Dan and paragraph 35 of Reid, cited by Examiner, have been reproduced herein 
as follows: 

FIG. 7 illustrates the development of the contract enforcement code and its 
integration with a service application , according to an embodiment of the present 
invention. First, in step 701, the parties create a joint formal document, referred to 
as the service contract. As indicated hereinabove, the service contract also can be 
created by a subset of the parties. The elements of one embodiment of the contract 
are detailed hereinbelow with regard to FIG. 9. The service contract is then 
registered, in step 710, by all interacting parties in their respective servers. This 
registration preferably includes storing of a service contract identification number, 
information regarding the service contract and the service contract itself. In a 
preferred embodiment, a tool is available for automatically generating 
enforcement code . The registration aids in this automatic generation of the parties' 
role-specific contract enforcement code. In the absence of such a tool, however, 
the code is written by hand, capturing the rules of interaction specified in the 
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contract. The code also contains information on the local application, such as how 
to invoke the local application, what specific method to call upon receiving a 
specific message, request or document. Finally, in step 720, the contract 
enforcement code is generated and integrated with the service implementation 
code for enabling actual runtime invocation . 



FIG. 8 illustrates the use of the contract enforcement code during runtime, 
according to an embodiment of the present invention. In step 800, an external 
request (or message, or document) arrives at a particular enforcement code 
component. The contract enforcement code then determines, based on the 
incorporated rules of interaction, the current interaction state and the interaction 
history of the service (e.g., requests and responses received), and whether such a 
request (or message, or document) is acceptable from the specific requester as per 
the rules of interaction , in step 810. If the request is determined to be acceptable, 
the contract enforcement code invokes, in step 820, an appropriate application 
method (or program). After the appropriate service implementation logic is 
executed to provide this service, a response may be generated. Note that the 
execution may be synchronous or asynchronous with the client request. The 
service logic may be a simple program or a multi-step execution synchronously or 
asynchronously involving business rules and internal methods where the business 
rules specify how the next method or execution step is to be selected. That is, the 
service logic may be adapted to suppoit long-running interactions or sequences of 
interactions which are timed apart. For example, the logic can support a situation 
in which a customer requests a reservation with a hotel service provider and 
requests a cancellation days later. In this example, the service contract of the 
present invention will capture the rules of interaction for such timed-apart 
interactions. The service logic may also make requests on other partners via other 
service contract enforcement code or via the same contract enforcement code. 
Hence, if there is a response to the original request, the service implementation 
logic sends the response to the particular contract enforcement code, in step 830. 
The contract enforcement code may add this response to the history of 
interactions, before sending it back to the original requester. Finally, if the 
original request is determined to be unacceptable, in step 810, the requester may 
be notified of this rejection in step 840. The contract enforcement code may also 
specify independent action to be taken by a partner in the absence of a response 
from another partner within a pre-specified time. 

[0035] The database of the present invention has extensive search capabilities. In 

one embodiment, there are three main search screens; agreement search, 
obligation search and docket search. The agreement search screen allows a user to 
search for agreements based on several fields including but not limited to: 
agreement number, agreement type, agreement sub-type, agreement summary, 
product line, intellectual property team, business unit, product group, parties, 
effective date, expiration date, attorney, paralegal, agreement requester, and 
agreement owner. An agreement summary is also full-text searchable and allows 
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the user to search using the "and" and "or" Boolean operators. The obligation 
search screen in this embodiment allows a user to search for obligations or 
obligation triggering events that meet certain criteria such as belonging to certain 
agreement types, owner, due date etc using both obligation and agreement fields. 

Appellant respectfully disagrees with Examiner's arguments. As can be seen from 
the above quoted passages, Dan teaches that in step 800, an external request (or 
message, or document) arrives at a particular enforcement code component. 
Clearly, in Dan the request arrives at the contract enforcement code, but does not 
include the contract enforcement code. Therefore, Dan does not teach "including 
said contract data into a request for said service" as recited in claim 14. 

Reid teaches that the agreement search screen allows a user to search for 
agreements based on several fields. However, Reid also does not teach the 
inclusion of the contract data (including contract selection parameters) into a 
request. As discussed in the Appeal Brief, the Appellants' claimed invention has 
the advantage that by including contract selection parameters into the service 
request, the requestor can have influence on the contract selection. 

For the reasons set forth in the Appeal Brief, and for those set forth herein, 
Appellants respectfully solicit the Honorable Board to reverse the Examiner's 
rejections. Please charge any shortage in fees due in connection with the filing of this 
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paper, if any, to Deposit Account 09-0461, and please credit any excess fees to such 
deposit account. 



Date: October 24, 201 1 Respectfully submitted, 

/Steven M. Greenberg/ 
Steven M. Greenberg 
Registration No. 44,725 
Customer Number 46320 
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